Arquitectura de información y conversión en webs B2B

La conversión web B2B no se recorre como una tienda. Alguien descubre, alguien compara, alguien pide una propuesta y alguien de legal o compras revisa. La arquitectura de información tiene que servir a ese recorrido, no a una galería de pantallas.

Este artículo ordena las páginas que de verdad se abren, cómo se enseña la prueba sin inventar cifras y qué suele fallar cuando el rediseño se inspira en un portfolio visual y no en el proceso de compra.

En resumen

• El recorrido habitual es conocer, entrar en shortlist, pedir alcance y pasar por legal o compras. Cada fase necesita una página, no un único botón de “contactar”.
• Las plantillas críticas son home, servicio, prueba (casos o método), compliance cuando el sector lo exige, y contacto.
• La prueba se ordena: qué se hizo, con quién, cómo. Sin métricas que la empresa no pueda enseñar.
• El formulario pide lo mínimo para continuar una conversación seria: rol, tipo de proyecto, plazo y si hay brief.

Ese recorrido es el desarrollo web que después se diseña: una página por fase, no un único botón de contacto.

Conversión web B2B: el recorrido, sin disfrazarlo de tienda

Si todas las rutas terminan en el mismo formulario genérico, quien llega no distingue en qué fase está. El contenido puede ser el mismo equipo y el mismo oficio. La página tiene que decir en qué momento ayuda.

Qué hace cada plantilla cuando alguien de compras abre el sitio

Un director digital llega desde un artículo o desde una recomendación. En la home tiene que entender el oficio y el tipo de proyecto. Si la home es un manifiesto de marca sin una frase operable —diseño y desarrollo de proyectos web y ecommerce, con SEO técnico y analítica—, sigue haciendo clic por inercia o se va. Las dos cosas pasan en menos de un minuto. No hace falta un párrafo de historia de la agencia para retenerle. Hace falta que la prueba (logos que se pueden enseñar, método) esté en la misma vista que la frase.

Servicio, prueba y contacto

En la página de servicio, la persona que construye la shortlist busca módulos comparables. Discovery, diseño, desarrollo, rendimiento, medición, handoff. Si eso está narrado como “acompañamiento integral” sin lista, no puede poner una marca en la columna de la hoja de cálculo con la que compras compara. La prosa puede ser buena y, aun así, la página se descarta si no se sabe qué se está contratando. El texto de servicio se escribe para esa hoja, no contra ella.

La prueba se abre en otra pestaña, casi siempre. Un caso que solo muestra la pieza visual obliga a volver a la home a buscar si hay equipo y proceso. Mejor un caso corto: situación de partida, restricción (idiomas, plataforma, otros partners, revisión interna), qué se hizo y qué quedó documentado para el equipo del cliente. Si no se puede nombrar al cliente, se cuenta el método con la restricción, sin disfrazarlo de caso con logo inventado. Un logo no autorizado es peor que un hueco.

Compliance, cuando el sector lo pide, no es un pie de página. Quien escribe desde legal busca consentimiento, accesibilidad y dónde están los datos. Si no hay ni un bloque, asume que no se ha pensado y lo apunta como riesgo de la shortlist. Un bloque sobrio —qué se implementa, qué decide el cliente— baja esa incertidumbre sin convertir la web en un dictamen.

El contacto es la última plantilla y la que más se diseña como resto. El formulario pide lo que la reunión siguiente va a usar. Rol, tipo de proyecto, plazo, si hay brief. El resto se pregunta en la conversación. Un formulario que parece una cualificación de lead de un anuncio de consumo produce envíos que nadie puede preparar, o no produce envíos.

Formularios y prueba, con el detalle que luego se diseña

En el wireframe, el formulario se dibuja con las etiquetas definitivas, no con “campo, campo, campo”. Cada etiqueta obliga a una decisión: ¿el plazo es un desplegable o un texto libre? Un desplegable con “urgente / este trimestre / este año” basta y se puede analizar. Un texto libre “¿cuándo lo necesitáis?” también basta si alguien lo va a leer. Los dos a la vez sobran.

La prueba al lado del formulario, o en la misma página de servicio, sigue el orden que un desconocido puede verificar. Primero logos públicos. Luego una cita con nombre y cargo ya publicada. Luego el método o el caso. El equipo al final de esa cadena, no como sustituto de la prueba: sirve para ver que hay diseño, desarrollo, SEO y SEM, y cuentas, no un único perfil. En dobleO ese reparto está en la ficha de equipo. La página no tiene que convertir a una persona en la cara del proyecto.

Lo que se inspira solo en una galería falla en un punto preciso: la primera pantalla impresiona y la segunda no responde “qué contratáis”. Se corrige en la arquitectura, antes de la ronda visual. Si la ronda visual ya está aprobada y la arquitectura no responde, la corrección parece un recorte creativo. No lo es. Es el contenido que el RFP iba a pedir de todas formas.

La URL es la arquitectura, no un detalle de la maqueta

Una página de servicio B2B se decide cuando se puede decir su URL, su canonical, su sitio en el menú y el único formulario que inicia la conversación. El sistema visual viene después. Si se diseña al revés, salen pantallas que no caben en ningún patrón y un menú que lista oficios con el mismo peso.

El patrón de URL

El patrón se fija pronto. Un servicio vive en /servicios/{slug}/, no a veces en la raíz y a veces en un subdominio de campaña. La barra final es una sola. El enlace interno, el canonical y el sitemap usan esa forma. La versión con parámetros de seguimiento no es otra página: la canonical apunta a la URL limpia y los utm se quedan para la medición. Si el canonical se construye con la query entera, cada anuncio compite consigo mismo. El idioma secundario no es un parámetro ?lang= perdido en plantillas sueltas. Es un prefijo —o un dominio, si de verdad hay una separación de mercado— con hreflang de ida y vuelta, incluida la autorreferencia. Un enlace de idioma que lleva a la home en lugar de a la misma página es un fallo de arquitectura de la información, aunque el botón esté bien dibujado.

Las plantillas son tipos, no un lienzo por URL. Home, servicio, artículo, contacto, landing de campaña. La landing reutiliza el componente de formulario del contacto y añade el bloque que la campaña necesita. Si la campaña se monta en otra herramienta, fuera del menú y fuera del modelo, hace falta decirlo: otra URL, otro evento, otro peso, y un enlace explícito de vuelta al servicio. Si no se dice, en la reunión se enseña un sitio y los anuncios envían a otro. Las facetas, en un ecommerce, se tratan igual de estrictas. Una combinación que no tiene demanda no gana una URL indexable. Se queda como estado de la lista, con canonical a la categoría, para no abrir un rastreo infinito de filtros cruzados. El buscador interno no se indexa.

Formulario y lo que no entra en el mapa

El formulario es parte del mapa, no un módulo decorativo al final. Una sola acción primaria por plantilla de servicio. Campos que la reunión siguiente sabe usar: empresa, rol, tipo de proyecto, si hay brief, idioma. La página de gracias, si existe, lleva noindex: no es una puerta de entrada, es un estado. El evento de conversión se ata a la respuesta correcta del servidor, de modo que un error de validación no cuente como lead. El estado de error se diseña —qué campo falla, sin perder lo ya escrito— porque un formulario que se vacía al fallar es una arquitectura de conversión rota, por mucho que el color del botón sea el de la marca.

Lo que queda fuera del mapa

Lo que no debe colarse en esta fase se marca en el mapa como fuera de plantilla: un área privada, un buscador con sesión, un configurador que solo funciona con un script de terceros. Si se cuela, el rendimiento y la infraestructura entran en el mapa. Un área con sesión no puede compartir caché pública con el sitio editorial. Un configurador que bloquea el hilo principal en la home es el INP de la plantilla que más se enseña. El mapa se dibuja para que marketing y sistemas vean qué URLs existen, cuál es la canonical, qué plantilla las pinta y qué formulario las convierte, antes de discutir la retícula.

Diseño traduce ese mapa a componentes con nombre. SEO y SEM comprueban que las URLs que ya reciben enlaces o anuncios tienen destino en el patrón, y que las que se retiran están en el mapa de redirecciones. Cuentas se asegura de que el menú de la cabecera no contradice el mapa: lo que esta fase quiere que se entienda cabe en la primera fila; el resto vive en el pie o en el cuerpo, no compite con el servicio. Cuando el mapa y el menú dicen cosas distintas, no es un problema de estilo. Son dos arquitecturas.

Errores de navegación que se pagan en tiempo

Un menú que lista todos los servicios con el mismo peso obliga a abrir cinco páginas para saber cuál es el encargo. Quien recibe el enlace no abre cinco páginas. Abre la que el compañero le reenvió y, si no responde, descarta. El menú puede ser completo en el pie. En la cabecera tiene que destacar el camino que queréis que se entienda en esta etapa: el proyecto web, el equipo, la prueba, el contacto. Lo demás existe. No compite en la primera fila.

Menú, landings y el mismo sitio

Otro error es hablar de “soluciones” sin decir el objeto. Solución de qué. Un director de sistemas busca plataforma, rendimiento, handoff. Un director de marketing busca mensaje, páginas, medición. Si el menú no usa esas palabras en algún sitio estable, cada uno busca en un buscador externo y aterriza en un artículo huérfano. El artículo tiene que devolver al servicio. El servicio tiene que usar las mismas palabras que el artículo. Si no, parecen dos empresas.

Las landings de campaña sueltas, fuera del menú y fuera de la plantilla, crean un tercer sitio. Convierten o no, según el anuncio, y no heredan la prueba ni el formulario acordado. Cuando se entra por esa landing, ve una oferta más estrecha que la de la home. A veces es deliberado. Muchas veces es que la plantilla no podía alojar la campaña y alguien la montó aparte. La arquitectura lo evita diseñando el módulo de campaña dentro del sistema, no prohibiendo las campañas.

Si esa landing aparte se ha justificado por peso o por un script que el sistema no admite, la conversación es de rendimiento e infraestructura. O se mete el módulo en el sistema y se mide, o se documenta la excepción y su evento. El mapa de páginas sirve para que el sitio que se enseña y el sitio que se anuncia sean el mismo.

Preguntas frecuentes

¿Hace falta un blog para que el sitio B2B convierta?

El blog ayuda a quien ya está comparando criterio. No sustituye a la página de servicio ni al formulario. Si el artículo no enlaza a una página que explique el encargo, el lector se queda en el artículo.

¿Los casos sin métricas convencen a compras?

Convencen si se entiende el problema y el método, y si el logo o la cita son públicos. Una métrica no autorizada convence menos y crea un problema legal.

¿La home tiene que hablar a todos los servicios de la agencia?

Tiene que orientar. Si todo pesa igual, no hay arquitectura. Los servicios que tienen que entenderse en una shortlist —en este ciclo, el proyecto web integral— necesitan una página propia, no un icono.

Siguiente paso

Con el recorrido escrito, la plataforma se elige por quién publica y qué hay que integrar, no por la demo.

En un proyecto de diseño y desarrollo web esa decisión va en el mismo alcance que las pantallas.

Siguiente en este ciclo: cómo elegir CMS.

Diego Quiñones · Technical Growth Architect en dobleO (Madrid). Arquitectura web, rendimiento, SEO técnico e infraestructura, junto al equipo de diseño, SEO y SEM, cuentas y dirección. Con el equipo dobleO.